Subject: Formalizing DLSw

From: "Jim (J.) Cobban" <[email-masked]>
Date: Mon, 4 Oct 1993 12:21:00 +0000

I would like to propose the following formalization of the DLSw
specification:

The function of a generalized data link switch can be viewed as consisting of
a core ability to switch data between virtual ports, and a set of data link
implementation specific adaption functions.  One graphical representation of
this concept is:

		 __________________
		/\                /\
	       /  \     SSP      /  \
	      /    \    over    /    \
	     /      \  TCP/IP  /      \
	    / SSP    \___vp___/ RFC1490\
	   /  over   /        \   over  \
	  /__ HPR   p          v   FR  __\
	 |   \__   v            p   __/   |
	 |      \ /              \ /      |
	 |       |                | QLLC  |
	 | etc.  v                v over  |
	 |       p     DLSw       p X.25  |
	 |       |                |       |
	 |    __/ \              / \__    |
	 |___/     v            p     \___|
	  \   HPR   p          v SDLC    /
	   \  over   \___vp___/  over   /
	    \  ATM   /        \  V.24  /
	     \      / IEEE802.2\      /
	      \    /    over    \    /
	       \  /   IEEE802.x  \  /
	        \__________________/

In this model the DLS specification requires the following:

  - signals passed over the DLSw to DLC specific interface.  These can be
    modelled on the OSI model of the data link service layer, and in
    particular on the expression of this layer in standard ISO 8802.2.
  - specification of the topology database maintained by the DLSw itself to
    implement the CANUREACH and NB_QUERY_NAME functions.
  - specification of the finite state machine for each connection maintained
    through the DLSw.
  - for specific examples of data link specific adaption functions, the
    mapping between the signals passed over the DLSw to DLC interface and
    the transmission medium, including finite state machines, if any, or
    equivalent.

As decided by the SIG the most important data link specific adaption
functions are:

  - the switch to switch protocol (SSP) over TCP/IP.  It is not my intention
    in this discussion to suggest any changes to this protocol, since we are
    very close to consensus.  I do suggest some changes to terminology.
  - SDLC for PU 1, PU 2, and PU 2.1 over serial links
  - IEEE 802.2 as used by SNA
  - IEEE 802.2 as used by NETBIOS.  I include this because although the SIG
    has agreed to defer discussion of this support, it does have an impact on
    the DLSw to DLC specific interface.  In particular NETBIOS Query Name is
    used for route discovery in place of CANUREACH.  

The Data Link Switch
--------------------

In this model the term Data Link Switch (DLSw) is limited to the actual
switching function and excludes all data link specific implementations,
including the Switch to Switch Protocol.

A Data Link Switch supports two or more virtual ports.  A virtual port is the
logical interface to an implementation specific Data Link Control instance.
In particular the interface between the Data Link Switch and the Switch to
Switch Protocol is a virtual port.  The implementation is layered such that
the Data Link Switch does not need to be aware of the implementation specific
characteristics of any of the data link implementations, including the SSP.

Each virtual port supports one or more logical link connections.  A logical
link connection provides a set of data transfer capabilities modelled on ISO
8802.2.  In addition the virtual port provides route discovery capabilities.

The primary purpose of the Data Link Switch is to transfer data and signals
between logical link connections.  Logical link connections are established
dynamically as a result of connection requests.

SNA uses 6 byte media access control (MAC) addresses to identify a logical
connection partner.  To support SNA connections the DLSw therefore maintains
a table which associates MAC addresses with virtual ports.  A single MAC
address may map to more than one virtual port, subject to a mechanism to be
determined by the loop-prevention SIGLET.  There are several mechanisms
defined by the architecture by which MAC addresses may be entered into this
table:

  - As a result of receiving an ICANREACH signal from a virtual port
  - From a list of MAC addresses provided in the Capabilities exchange
    signal from a virtual port

Note that the current architecture does not permit the DLSw to learn about a
MAC address from its presence as the source MAC address in a CANUREACH
message.  In this it differs from a conventional IEEE 802.1 transparent
bridge in which this is the primary mechanism.  Is this a reasonable
architectural decision?

For each virtual port there is an indicator as to whether or not CANUREACH
signals should be forwarded to that data link control instance.  This is set
as a result of the capabilities exchange with that data link control
instance.

For NETBIOS the resource name is used to identify a logical connection
partner.  There would need to be a resource name table in the DLSw with
characteristics similar to the MAC table used for SNA.

For each logical link connection over a virtual port the DLSw maintains a
connection instance which is also associated with another logical link
connection over a virtual port.  The connection instance identifies the two
logical link connections and contains a finite state machine which records
the progress of the connection.

Virtual Port Interface
----------------------

The following signals are exchanged across the virtual port interface between
the DLSw and the data link control instance.  In trying to combine the ISO
8802.2 data link interface model with the topology and connection setup
capabilities of the RFC's SSP protocol specification, I suggest that some
small modification of terminology may be useful.  The exact representation of
these signals is left for further development, although they should be as
similar as possible to the SSP messages.

 DL-CAPABILITIES request
	This is sent from the DLSw to the virtual port to signal the
	capabilities of the DLSw.

 DL-CAPABILITIES indication
	This is sent from a virtual port to the DLSw to signal the
	capabilities of the data link control instance.  This may contain the
	following optional parameters:

	- indicator of whether this data link instance does not wish to
	  receive DL-CANUREACH requests.  This is used to prune the broadcast
	  discovery tree.  
	- a list of MAC addresses which are to be added into the DLSw
	  MAC table to speed up discovery.  If this is combined with the
	  previous indicator it says that this is a complete list of all
	  MACs accessable through this virtual port.
	- a list of MAC address and bit mask pairs which are to be added into
	  the DLSw table to speed up discovery.  This is a more compact
	  representation which may be useful particularly for locally
	  administered MAC addresses.

 DL-CANUREACH request
	This is sent from the DLSw to the virtual port to propagate a
	broadcast topology search for a specific destination MAC.  The
	request must include the following parameters:

	- source virtual port
	- source MAC
	- source SAP
	- destination MAC
	- request procedure correlation identifier

 DL-CANUREACH indication
	This is sent from a virtual port to the DLSw to request the DLSw to
	provide assistance in locating a route to a specified destination
	MAC address.  The indication must include the following parameters:

	- source MAC
	- source SAP
	- destination MAC
	- request procedure correlation identifier

	On receipt of this indication the DLSw looks for a match in its MAC
	table on the destination MAC.  If a match is found, and if the
	corresponding virtual port accepts CANUREACH requests, then the
	indication is propagated to that virtual port as a request.  If a
	match is found and the virtual port does NOT accept CANUREACH
	requests, then the DLSw generates a CANUREACH response on behalf of
	the virtual port.  If no match is found then a copy of the CANUREACH
	indication is sent as a CANUREACH requests to each virtual port
	which accepts CANUREACH requests.

 DL-CANUREACH response
	This is sent from the DLSw to a virtual port to indicate that the MAC
	address previously requested as destination address in a DL-CANUREACH
	indication is reachable through this DLSw.  The response must include
	the following parameters.  Note that the terms source and destination
	are in relation to the original indication.  This signal corresponds
	to the SSP message currently called ICANREACH.

	- source MAC 
	- source SAP
	- destination MAC
	- request procedure correlation identifier

 DL-CANUREACH confirm
	This is sent from a virtual port to the DLSw to indicate that the MAC
	address previously requested as destination address in a DL-CANUREACH
	request is reachable through this virtual port.  Note that the terms
	source and destination are in relation to the original indication. 
	This signal corresponds to the SSP message currently called ICANREACH.
	The response must include the following parameters.

	- source virtual port
	- source MAC
	- source SAP
	- destination MAC
	- request procedure correlation identifier

 DL-CONNECT request
	This is sent from the DLSw to a virtual port.  It requests the
	establishment of a logical connection.  This corresponds to the
	functionality which in the current consensus is referred to as
	CANUREACH-2.

 DL-CONNECT indication
	This is sent from a virtual port to the DLSw.  It requests the
	establishment of a logical connection.  This corresponds to the
	functionality which in the current consensus is referred to as
	CANUREACH-2.

 DL-CONNECT response
	This is sent from the DLSw to a virtual port. It acknowledges the
	establishment of a logical connection and carries back parameters
	related to that connection from the far end.  This corresponds to the
	functionality which in the current consensus is referred to as
	ICANREACH-2.

 DL-CONNECT confirm
	This is sent from a virtual port to the DLSw.  It acknowledges the
	establishment of a logical connection and carries back parameters
	related to that connection from the far end.  This corresponds to the
	functionality which in the current consensus is referred to as
	ICANREACH-2.

 DL-ACCEPT request
	This is sent from the DLSw to a virtual port.  It completes the
	establishment of the logical connection through the DLSw.  This
	corresponds to the functionality which in the current consensus is
	referred to as ICANREACH-OK-2.

 DL-ACCEPT indication
	This is sent from a virtual port to the DLSw.  It completes the
	establishment of the logical connection through the DLSw.  This
	corresponds to the functionality which in the current consensus is
	referred to as ICANREACH-OK-2.

 DL-XID request
	This is sent from the DLSw to a virtual port. This signal carries the
	data field of an XID across an already established connection.  This
	corresponds to an XID "command" within the DLC specific context.
	DL-XID is used for PU 2.1 parameter exchanges and may be used on
	PU 2 parameter exchanges.

 DL-XID indication
	This is sent from a virtual port to the DLSw.  This signal carries
	the data field of an XID across an already established connection. 
	This corresponds to an XID "command" within the DLC specific context.

 DL-XID response
	This is sent from the DLSw to a virtual port. This signal carries the
	data field of an XID across an already established connection.  This
	corresponds to an XID "response" within the DLC specific context.

 DL-XID confirm
	This is sent from a virtual port to the DLSw.  This signal carries
	the data field of an XID across an already established connection. 
	This corresponds to an XID "response" within the DLC specific context.

 DL-DATA request
 DL-DATA indication
	These signals carry the data field of an I frame across an already
	established connection.  Note that IBM never sends response type I
	frames on SNA connections.

 DL-UNITDATA request
 DL-UNITDATA indication
 DL-UNITDATA response
 DL-UNITDATA confirm
	These signals carry the data field of a UI frame across an already
	established connection.  These signals are used by NETBIOS.  I do not
	know if NETBIOS uses the C/R bit in the SSAP.

 DL-DISCONNECT request
 DL-DISCONNECT indication
 DL-DISCONNECT response
 DL-DISCONNECT confirm
	These signals tear down an already established connection.  

Switch-to-Switch Protocol Data Link Control
---------------------------------------------------

In the SSP DLC implementation, the signals exchanged across the virtual port
interface are mapped to the SSP protocol as currently defined by RFC1434 with
the exception of the separation of topology establishment from circuit
establishment.  However I suggest that the above terminology may be clearer
than that in the existing document.

By an extension the SSP may be carried over a reliable transport other than
TCP/IP, for example HPR or OSI TP0/CONS or TP4/CLNS.

IEEE 802.2 LLC 2
----------------

The 802.2 data link control implementation generates signals to the DLSw in
the following way:

 DL-CAPABILITIES indication
	This is sent from a virtual port to the DLSw to signal the
	capabilities of the data link control instance.  The contents of this
	signal is obtained from configuration data or implementation
	decisions.  The list of MAC addresses to be added into the DLSw MAC
	table may be determined by listening to SMACs on the LAN.

 DL-CANUREACH indication
	This is sent from a virtual port to the DLSw to request the DLSw to
	provide assistance in locating a route to a specified destination
	MAC address.  It is generated as a result of receipt of a TEST frame
	from a particular source MAC requesting route discovery for an
	unknown destination MAC.

 DL-CANUREACH confirm
	This is sent from a virtual port to the DLSw to indicate that the MAC
	address previously requested as destination address in a DL-CANUREACH
	request is reachable through this virtual port.  This is generates as
	a result of receipt of a TEST response frame carrying route
	information for a particular destination MAC, while a DL-CANUREACH
	request is pending.

 DL-CONNECT indication
	This is sent from a virtual port to the DLSw.  It requests the
	establishment of a logical connection.  This is generated as a result
	of receipt of an XID or SABME for a particular SMAC, DMAC, SSAP, DSAP
	quadruple.

 DL-CONNECT confirm
	This is sent from a virtual port to the DLSw.  It is sent as response
	to a DL-CONNECT request from the DLSw.  If the type of destination
	station requires an XID exchange, no frames have been exchanged with
	the station.  This is always true for a T2.1 node, almost always true
	for a T2 node.  See the handling of a DL-CONNECT request below for
	further considerations.  If the device does not support XID then this
	signal is generated as a result of a UA response to SABME.  If the
	device supports a null-XID contact poll then this signal is generated
	as a result of a response to null-XID.

 DL-ACCEPT indication
	This is sent from a virtual port to the DLSw.  It completes the
	establishment of the logical connection through the DLSw.  This
	is a response to receipt of a DL-CONNECT response. 

 DL-XID indication
	This is sent from a virtual port to the DLSw.  This signal carries
	the data field of an XID across an already established connection. 
	This is sent to carry the contents of an XID frame received from the
	link with the C/R bit in the SSAP set to command.

 DL-XID confirm
	This is sent from a virtual port to the DLSw.  This signal carries
	the data field of an XID across an already established connection. 
	This is sent to carry the contents of an XID frame received from the
	link with the C/R bit in the SSAP set to response.

 DL-DATA indication
	This signal carries the data field of an I frame across an already
	established connection.

 DL-UNITDATA indication
	This signal carries the data field of a UI frame across an already
	established connection.

 DL-DISCONNECT indication
	This signal indicates that the logical connection has been torn down
	by the data link control.  This is sent as a result of receipt of
	DISC from the link, or as a result of logical link failure, for
	example retransmission failure.

 DL-DISCONNECT confirm
	This signal is the response to DL-DISCONNECT request.  It indicates
	that the logical connection which the DLSw has requested to be
	terminated is down.  This is sent as a result of receipt of UA from
	the link in response to a DISC frame.

The DLC takes the following actions on receipt of signals from the DLSw.

 DL-CAPABILITIES request
	This is sent from the DLSw to the virtual port to signal the
	capabilities of the DLSw.

 DL-CANUREACH request
	This is sent from the DLSw to the virtual port to propagate a
	broadcast topology search for a specific destination MAC.  The
	DLC generates a TEST frame with all-routes discovery set.

 DL-CANUREACH response
	This is sent from the DLSw to a virtual port to indicate that the MAC
	address previously requested as destination address in a DL-CANUREACH
	indication is reachable through this DLSw.  The DLC generates a TEST
	frame with RI field set complementary to the setting in the TEST
	frame which triggered the original DL-CANUREACH indication.

 DL-CONNECT request
	This is sent from the DLSw to a virtual port.  If the attached device
	does not require, or does not support, an XID exchange prior to
	entering asynchronous balanced mode, then this frame causes a SABME
	to be sent on the link.  If the attached device supports receipt of a
	null XID then one is sent.  See DL-CONNECT confirm above.

 DL-CONNECT response
	This is sent from the DLSw to a virtual port. It acknowledges the
	establishment of a logical connection and carries back parameters
	related to that connection from the far end.  A DL-ACCEPT indication
	is sent to the DLSw to complete the connection.

 DL-ACCEPT request
	This is sent from the DLSw to a virtual port.  It completes the
	establishment of the logical connection through the DLSw.  If the pending
	DL-CONNECT indication was sent as a result of receipt of a SABME then
	a UA frame is sent on the LAN.  If the pending DL-CONNECT indication
	was sent as a result of receipt of an XID then a DL-XID is sent to
	the DLSw to carry the contents of the XID.

 DL-XID request
	This is sent from the DLSw to a virtual port. This signal carries the
	data field of an XID across an already established connection.  This
	results in sending an XID frame with the C/R bit in the SSAP set to
	command.

 DL-XID response
	This is sent from the DLSw to a virtual port. This signal carries the
	data field of an XID across an already established connection.  This
	results in sending an XID frame with the C/R bit in the SSAP set to
	response.

 DL-DATA request
	These signals carry the data field of an I frame across an already
	established connection.  Note that IBM never sends response type I
	frames on SNA connections.

 DL-UNITDATA request
	These signals carry the data field of a UI frame across an already
	established connection.  These signals are used by NETBIOS.  I do not
	know if NETBIOS uses the C/R bit in the SSAP.

 DL-DISCONNECT request
	This is sent from the DLSw to a virtual port.  A DISC frame is
	transmitted on the LAN.

 DL-DISCONNECT response
	This is sent from the DLSw to a virtual port.  A UA frame is sent to
	acknowledge a previous DISC.

Note that if an XID exchange is required in order to exchange parameters
prior to entering asynchronous balanced mode then the LLC 2 DLC instance
which receives an XID frame from the LAN in which the adjacent station
accepts being the secondary automatically sends the SABME.  Similarly the
LLC2 DLC instance which has accepted being the secondary locally responds to
SABME.  The following summarizes the end-to-end flows for a T2.1 activation:

 T2.1         LLC2 DLC             DLSw            LLC2 DLC         T2.1
  | TEST         | DL-CUR ind       | DL-CUR request  | TEST         |
  |------------->|----------------->|---------------->|------------->|
  |        TEST  |   DL-CUR resp    |  DL-CUR confirm |        TEST  |
  |<-------------|<-----------------|<----------------|<-------------|
  | XID          | DL-CONNECT ind   | DL-CONNECT req  | XID (null)   |
  |------------->|----------------->|---------------->|------------->|
  |              |   DL-CONNECT resp|  DL-CONNECT conf|         XID  |
  |              |<-----------------|<----------------|<-------------|
  |              | DL-ACCEPT ind    | DL-ACCEPT req   |              |
  |              |----------------->|---------------->|              |
  |              | DL-XID ind       | DL-XID request  | XID          |
  |              |----------------->|---------------->|------------->|
  |        XID   |   DL-XID resp    |  DL-XID confirm |        XID   |
  |<-------------|<-----------------|<----------------|<-------------|
  | XID          | DL-XID ind       | DL-XID request  | XID          |
  |------------->|----------------->|---------------->|------------->|
  |        XID   |   DL-XID resp    |  DL-XID confirm |        XID   |
  |<-------------|<-----------------|<----------------|<-------------|
  | SABME        |                  |                 | SABME        |
  |------------->|                  |                 |------------->|
  |         UA   |                  |                 |         UA   |
  |<-------------|                  |                 |<-------------|
  |              |                  |                 |              |

The logical link level is activated locally in order to retain the normal
sense of the DL-CONNECT primitive in IEEE 802.2 without at the same time
requiring a change to the SSP protocol which we have already accepted.  For
example for a T2 node which does not require an XID exchange the above
set of flows reduces to:

 NCP          LLC2 DLC             DLSw            LLC2 DLC         T2.1
  | TEST         | DL-CUR ind       | DL-CUR request  | TEST         |
  |------------->|----------------->|---------------->|------------->|
  |        TEST  |   DL-CUR resp    |  DL-CUR confirm |        TEST  |
  |<-------------|<-----------------|<----------------|<-------------|
  | SABME        | DL-CONNECT ind   | DL-CONNECT req  | SABME        |
  |------------->|----------------->|---------------->|------------->|
  |          UA  |   DL-CONNECT resp|  DL-CONNECT conf|          UA  |
  |<-------------|<-----------------|<----------------|<-------------|

Synchronous Data Link Control
-----------------------------
Because of its long history there is a great deal of variability in handling
of SDLC frames.  This section will require considerable work.

SDLC requires an address mapping capability in its configuration data. This
must be specified in the DLSw architecture.  The following is a suggestion:

In SDLC the link level address is a one byte value.  Only the address of the
secondary link station is used on the link.  Since each SDLC secondary link
station can only support a single logical link connection that one byte value
must be mapped to the entire SMAC, DMAC, SSAP, DSAP 4-tuple which identifies
a logical link connection on the DLSw.

The SDLC data link control implementation generates signals to the DLSw in
the following way:

 DL-CAPABILITIES indication
	This is sent from a virtual port to the DLSw to signal the
	capabilities of the data link control instance.  The contents of this
	signal is obtained from configuration data or implementation
	decisions.  SDLC does not use MAC addresses, so the contents of the
	list of MAC addresses table will depend upon configuration data.

 DL-CANUREACH indication
	This is sent from a virtual port to the DLSw to request the DLSw to
	provide assistance in locating a route to a specified destination
	MAC address.  If the SDLC instance is acting as a secondary or
	configurable station this signal is sent as a result of receipt of the
	first frame from a particular attached station.  If the SDLC instance
	is acting as a primary station this signal is sent as a result of
	receiving a response to a contact poll, that is a UA response to SNRM
	or an XID response to null-XID, depending upon configuration.  

 DL-CANUREACH confirm
	This is sent from a virtual port to the DLSw to indicate that the MAC
	address previously requested as destination address in a DL-CANUREACH
	request is reachable through this virtual port.  This is generated as
	a result of receipt of a DL-CANUREACH request carrying a destination
	MAC which is configured on this port.  There is no guaranteed safe
	mechanism for extending CANUREACH to the SDLC link level.  If the
	SDLC instance is operating as a secondary station then it may choose
	not to respond to DL-CANUREACH request if it has not received a poll
	for the associated secondary address recently.  If the SDLC instance
	is operating as a primary station it may choose not to respond if it
	has not received a response to contact poll (SNRM or null-XID).  If
	the SDLC instance is operating as a configurable station it may need
	to wait for DL-XID information before sending any frame to the
	adjacent link station.  In some cases, although this is contrary to
	existing practice, a TEST frame could be sent.

 DL-CONNECT indication
	This is sent from a virtual port to the DLSw.  It requests the
	establishment of a logical connection.  This is generated as a result
	of receipt of an XID or SNRM[E] for a particular configured device.

 DL-CONNECT confirm
	This is sent from a virtual port to the DLSw.  It is sent as response
	to a DL-CONNECT request from the DLSw.  If the type of destination
	station requires an XID exchange, no frames have been exchanged with
	the station.  This is always true for a T2.1 node, and often true
	for a T2 node.  See the handling of a DL-CONNECT request below for
	further considerations.  If the station only supports SNRM contact
	poll then this signal is generated in response to a UA
	acknowledgement of a SNRM.  If the station supports null-XIDS contact
	poll then this signal is generated in response to an XID.

 DL-ACCEPT indication
	This is sent from a virtual port to the DLSw.  It completes the
	establishment of the logical connection through the DLSw.  This
	is a response to receipt of a DL-CONNECT response. 

 DL-XID indication
	This is sent from a virtual port to the DLSw.  This signal carries
	the data field of an XID across an already established connection. 
	This is sent to carry the contents of an XID frame received from the
	link.  If the SDLC instance is secondary (poll responder) then this
	is sent for all received XIDs.  If the SDLC is primary (poller) then
	this is NEVER sent.  If the SDLC instance is configurable then DL-XID
	indication is sent whenever it is required by the behavior of LAN
	based implementations of T2.1 nodes.

 DL-XID confirm
	This is sent from a virtual port to the DLSw.  This signal carries
	the data field of an XID across an already established connection. 
	If the SDLC instance is secondary (poll responder) then this
	is NEVER sent.  If the SDLC is primary (poller) then this is sent
	for all received XIDs.  If the SDLC instance is configurable then
	DL-XID confirm is sent whenever it is required by the behavior of LAN
	based implementations of T2.1 nodes.

 DL-DATA indication
	This signal carries the data field of an I frame across an already
	established connection.

 DL-UNITDATA indication
	This signal carries the data field of a UI frame across an already
	established connection.

 DL-DISCONNECT indication
	This signal indicates that the logical connection has been torn down
	by the data link control.  This is sent as a result of receipt of
	DISC or RD from the link, or as a result of logical link failure, for
	example retransmission failure.

 DL-DISCONNECT confirm
	This signal is the response to DL-DISCONNECT request.  It indicates
	that the logical connection which the DLSw has requested to be
	terminated is down.  This is sent as a result of receipt of UA from
	the link in response to a DISC frame or DISC in response to a RD.

The DLC takes the following actions on receipt of signals from the DLSw.

 DL-CAPABILITIES request
	This is sent from the DLSw to the virtual port to signal the
	capabilities of the DLSw.

 DL-CANUREACH request
	This is sent from the DLSw to the virtual port to propagate a
	broadcast topology search for a specific destination MAC.  The
	DLC responds with a DL-CANUREACH confirm if the requested destination
	MAC is in its configuration data.  No frame goes on the link.

 DL-CANUREACH response
	This is sent from the DLSw to a virtual port to indicate that the MAC
	address previously requested as destination address in a DL-CANUREACH
	indication is reachable through this DLSw.  The SDLC instance sends
	a DL-CONNECT indication to the DLSw.

 DL-CONNECT request
	This is sent from the DLSw to a virtual port.  It causes a
	null XID or SNRM contact poll to be sent, if the SDLC instance is
	primary.  If the SDLC instance is secondary it simply conditions the
	instance to respond to future contact polls.  In the case of a
	configurable instance a DL-CONNECT confirm may be sent to DLSw because
	the instance requires a DL-XID.

 DL-CONNECT response
	This is sent from the DLSw to a virtual port. It acknowledges the
	establishment of a logical connection and carries back parameters
	related to that connection from the far end.  A DL-ACCEPT indication
	is sent to the DLSw to complete the connection.  If the SDLC instance
	is secondary it simply conditions the instance to respond to future
	contact polls.  In the case of a configurable instance a DL-ACCEPT
	indication may be sent to DLSw because the instance requires a DL-XID.

 DL-ACCEPT request
	This is sent from the DLSw to a virtual port.  It completes the
	establishment of the logical connection through the DLSw.  If the pending
	DL-CONNECT indication was sent as a result of receipt of a SNRM then
	a UA frame is sent on the link.  If the pending DL-CONNECT indication
	was sent as a result of receipt of an XID then a DL-XID is sent to
	the DLSw to carry the contents of the XID.

 DL-XID request
	This is sent from the DLSw to a virtual port. This signal carries the
	data field of an XID across an already established connection.  This
	results in sending an XID frame.  The address field in the XID frame
	is determined by a finite state machine depending upon the link
	configuration, rather than by whether a request or response is
	received from DLSw.

 DL-XID response
	This is sent from the DLSw to a virtual port. This signal carries the
	data field of an XID across an already established connection.  This
	results in sending an XID frame.  The address field in the XID frame
	is determined by a finite state machine depending upon the link
	configuration, rather than by whether a request or response is
	received from DLSw.

 DL-DATA request
	These signals carry the data field of an I frame across an already
	established connection.  Note that IBM never sends response type I
	frames on SNA connections.

 DL-UNITDATA request
	These signals carry the data field of a UI frame across an already
	established connection.  These signals are used by NETBIOS.  I do not
	know if NETBIOS uses the C/R bit in the SSAP.

 DL-DISCONNECT request
	This is sent from the DLSw to a virtual port.  A DISC frame is
	transmitted on the LAN.

 DL-DISCONNECT response
	This is sent from the DLSw to a virtual port.  A UA frame is sent to

Note that if an XID exchange is required in order to exchange parameters
prior to entering normal response mode then the SDLC DLC instance
which receives an XID frame from the link in which the adjacent station
accepts being the secondary automatically sends the SNRM.  Similarly the
SDLC DLC instance which has accepted being the secondary locally responds to
SNRM.  The following summarizes the end-to-end flows for a T2.1 activation:

 T2.1         SDLC DLC             DLSw            SDLC DLC         T2.1
  | XID          | DL-CUR ind       | DL-CUR request  |              |
  |------------->|----------------->|---------------->|              |
  |              |   DL-CUR resp    |  DL-CUR confirm |              |
  |              |<-----------------|<----------------|              |
  |              | DL-CONNECT ind   | DL-CONNECT req  | null-XID     |
  |              |----------------->|---------------->|------------->|
  |              |   DL-CONNECT resp|  DL-CONNECT conf|         XID  |
  |              |<-----------------|<----------------|<-------------|
  |              | DL-ACCEPT ind    | DL-ACCEPT req   |              |
  |              |----------------->|---------------->|              |
  |              | DL-XID ind       | DL-XID request  | XID          |
  |              |----------------->|---------------->|------------->|
  |        XID   |   DL-XID resp    |  DL-XID confirm |        XID   |
  |<-------------|<-----------------|<----------------|<-------------|
  | XID          | DL-XID ind       | DL-XID request  | XID          |
  |------------->|----------------->|---------------->|------------->|
  |        XID   |   DL-XID resp    |  DL-XID confirm |        XID   |
  |<-------------|<-----------------|<----------------|<-------------|
  | SNRM         |                  |                 | SNRM         |
  |------------->|                  |                 |------------->|
  |         UA   |                  |                 |         UA   |
  |<-------------|                  |                 |<-------------|
  |              |                  |                 |              |

The logical link level is activated locally in order to retain the normal
sense of the DL-CONNECT primitive in IEEE 802.2 without at the same time
requiring a change to the SSP protocol which we have already accepted.  For
example for a T2 node which does not require an XID exchange the above
set of flows reduces to:

 NCP          SDLC DLC             DLSw            SDLC DLC         T2
  | SNRM         | DL-CUR ind       | DL-CUR request  |              |
  |------------->|----------------->|---------------->|              |
  |              |   DL-CUR resp    |  DL-CUR confirm |              |
  |              |<-----------------|<----------------|              |
  | SNRM         | DL-CONNECT ind   | DL-CONNECT req  | SNRM         |
  |------------->|----------------->|---------------->|------------->|
  |          UA  |   DL-CONNECT resp|  DL-CONNECT conf|          UA  |
  |<-------------|<-----------------|<----------------|<-------------|